Optimizing an interrupt-latency or a polling rate for a hardware platform and network profile combination

ABSTRACT

Provided are techniques for determining a timer value. An advised number of packets per interrupt for both receive and transmit directions of traffic is determined. Current timer values for both receive and transmit directions of traffic are adjusted based on the determined advised numbers of packets per interrupt. A new timer value to be used for both receive and transmit directions of traffic is calculated. Other embodiments are described and claimed.

BACKGROUND

Modern network hardware uses various schemes for moderating orcoalescing interrupts in order to improve performance (e.g., throughputor Central Processing Unit (CPU) utilization). Many of these schemes arenot versatile enough to handle different hardware platforms (i.e.,computer systems) or different network profiles, due to the large numberof unbound algorithmic parameters that may be tuned per hardwareplatform or per configuration. That is, conventional schemes are notgeneric enough.

Different hardware platforms may be described as computer systems withdifferent latencies, due to memory, CPU, and other hardware andoperating system factors. For example, an Intel® Pentium® 4 hardwareplatform has different latencies than an Intel® Pentium® 3 hardwareplatform. A network profile may be described as a set of characteristicsof a network, including line utilization, link speed, direction oftraffic (e.g., transmit, receive or mixed (i.e., both receive andtransmit)), average packet size, and burstness (i.e., amount of datasent or received over time).

An interrupt throttling rate (ITR) scheme may be described as atechnique to delay an interrupt event using a settable timer. That is,the interrupt is issued when the timer reaches a set value. Whenpracticing the ITR scheme, it is difficult to find an appropriatethrottling rate for various combinations of hardware platforms andnetwork profiles. A throttling rate may be described as the rate atwhich interrupts are issued. In conventional systems, there is noalgorithmic way to find an optimal ITR value for a combination of aparticular hardware platform and network profile.

The ITR scheme may be impacted by the hardware platform. For example,once an interrupt is fired, the latency of servicing the interruptcauses a deviation from the original planned time. Latency, in thiscase, refers to the amount of time it takes for a packet of data to getfrom the hardware receive queue to the target application that uses thepacket of data. This deviation changes from one hardware platform toanother. Furthermore, the latency changes in the same hardware platformas the network profile changes since the hardware platform goes throughdifferent levels of workload.

With reference to the network profile, the network profile affects, byitself, the packet handling latency. When trying to optimize theperformance of a hardware platform, each network profile for thathardware platform requires a different throttling rate, where eachthrottling rate behaves differently on a different hardware platform.Thus, it is not effective to treat all network profiles as the same andassociate a static ITR value for each network profile and hardwareplatform combination.

An example of a problematic network profile is a case in which a smallpacket test (in a Gigabit network) yields packets in rates of up to of1.4 million packets per second (PPS). A long latency causes the internalbuffers of the hardware to overflow, since an interrupt service routinemay be scheduled too late. A short latency probably services thepackets, but a very fast machine with a very short response time ends upwith too many interrupts. There should be a tradeoff among the two, butconventional systems do not provide a reasonable approximation.

The ITR scheme is used today, but there is no technique to match theinterrupt throttling rate for every hardware platform and networkprofile. The current state is that products on the market either imposethe tuning responsibility on the user or system administrator or usestatic values that are not appropriate for all scenarios.

Polling may be described as a technique in which interrupts are issuedat specific (e.g., scheduled) time intervals. The use of a settabletimer in an ITR schema in a given platform and network profile may beimitated by using a polling timer, since the average rate of theinterrupts is anticipated and may be handled in a given time delay.

Therefore, there is a need in the art for an improved technique foroptimizing an interrupt-latency or polling rate value for use with ahardware platform and network profile combination.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 illustrates a computing environment in accordance with certainembodiments.

FIG. 2 illustrates further details of an optimizer and network adapterin accordance with certain embodiments.

FIG. 3 illustrates the interaction between a statistics processingmodule, a dynamic tuning module, and a runtime network core inaccordance with certain embodiments.

FIG. 4 illustrates operations for determining an optimal ITR value inaccordance with certain embodiments.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the following description, reference is made to the accompanyingdrawings which form a part hereof and which illustrate severalembodiments. It is understood that other embodiments may be utilized andstructural and operational changes may be made without departing fromthe scope of embodiments.

FIG. 1 illustrates details of a computing device 100 in accordance withcertain embodiments. The computing device 100 (e.g., a host computer)includes one or more central processing units (CPUs) 104 (i.e.,processors), a volatile memory 106, non-volatile storage 108 (e.g.,magnetic disk drives, optical disk drives, a tape drive, etc.), and oneor more network adapters 128.

Memory 106 stores an operating system 110. The operating system 110 mayinclude operating system drivers, such as an operating system driver111. One or more network drivers 120, one or more application programs124, and an optimization system 126 may be stored in memory 106. Theoptimization system 126 enables optimization of an interrupt-latency(i.e., throttling rate) and/or a polling rate. Polling may be describedas a technique in which operations are performed in specific (e.g.,scheduled) time intervals.

The computing device 100 may comprise any suitable computing device,such as a mainframe, server, personal computer, workstation, laptop,handheld computer, telephony device, network appliance,.virtualizationdevice, storage controller, etc. Any suitable CPU 104 and operatingsystem 110 may be used. Programs and data in memory 106 may be swappedinto storage 108 as part of memory management operations.

Communication path 170 may be any type of network such as, for example,a Storage Area Network (SAN), a Local Area Network (LAN), Wide AreaNetwork (WAN), the Internet, an Intranet, bus, etc.

In various embodiments, the optimization system 126 may be part of anetwork driver that controls network hardware or within the networkhardware itself. In certain embodiments, the optimization system 126 mayexist as an external entity, such as a process or driver. In certainembodiments, the optimization system 126 may exist within a specificprocess (e.g., an application program 124) or driver that is hosted bythe operating system 110. In alternative embodiments, the optimizationsystem 126 may be part of another component (hardware and/or software)coupled to computing device 100.

Each network adapter 128 includes various components implemented in thehardware of the network adapter 128. Each network adapter 128 is capableof transmitting and receiving packets of data over communication path170.

Each network driver 120 executes in memory 106 and includes networkadapter 128 specific commands to communicate with each network adapter128 and interface between the operating system 110 and each networkadapter 128. Each network adapter 128 or network driver 120 implementslogic to process packets, such as a transport protocol layer to processthe content of messages included in the packets that are wrapped in atransport layer, such as Transmission Control Protocol (TCP) and/orInternet Protocol (IP), the Internet Small Computer System Interface(iSCSI) (IETF RFC 1347, published February 2003), Fibre Channel(American National Standards Institute (ANSI) X3.269-199X, Revision 012,Dec. 4, 1995), or any other suitable transport layer protocol.

A bus controller 134 enables each network adapter 128 to communicate ona computer bus 160, which may comprise any suitable bus interface, suchas any type of Peripheral Component Interconnect (PCI) bus (e.g., a PCIbus (PCI Special Interest Group, PCI Local Bus Specification, Rev 2.3,published March 2002), a PCI-X bus (PCI Special Interest Group, PCI-X2.0a Protocol Specification, published 2002), or a PCI Express bus (PCISpecial Interest Group, PCI Express Base Specification 1.0a, published2002), published March 2002), Small Computer System Interface (SCSI)(American National Standards Institute (ANSI) SCSI Controller Commands-2(SCC-2) NCITS.318:1998), Serial ATA (SATA 1.0a Specification, publishedFeb. 4, 2003), etc.

The network adapter 128 includes a network protocol for implementing aphysical communication layer 132 to send and receive network packets toand from remote data storages over the communication path 170. Incertain embodiments, the network adapter 128 may implement the Ethernetprotocol, or any other suitable network communication protocol.

The network adapter 128 includes an Input/Output (I/O) controller 130.In certain embodiments, the I/O controller 130 may comprise InternetSmall Computer System Interface (iSCSI controllers), and it isunderstood that other types of network controllers, such as an EthernetMedia Access Controller (MAC) or Network Interface Controller (NIC), orcards may be used.

The storage 108 may comprise an internal storage device or an attachedor network accessible storage. Programs in the storage 108 may be loadedinto the memory 106 and executed by the CPU 104. An input device 150 isused to provide user input to the CPU 104, and may include a keyboard,mouse, pen-stylus, microphone, touch sensitive display screen, or anyother suitable activation or input mechanism. An output device 152 iscapable of rendering information transferred from the CPU 104, or othercomponent, such as a display monitor, printer, storage, etc.

In certain embodiments, in addition to one or more drivers 120, thecomputing device 100 may include other drivers, such as a transportprotocol driver (not shown) that performs the functions of the transportprotocol layer.

The network adapter 128 may include additional logic to performadditional operations to process received packets from the computer 100or the communication path 170. Further, the network adapter 128 mayimplement a transport layer offload engine (TOE) to implement thetransport protocol layer in the network adapter as opposed to thenetwork driver 120 to further reduce computing device processingburdens. Alternatively, the transport layer may be implemented in anetwork driver 120.

Various structures and/or buffers (not shown) may reside in memory 106or may be located in a storage unit separate from the memory 106 incertain embodiments.

FIG. 2 illustrates further details of an optimization system 126 andnetwork adapter 128 in accordance with certain embodiments. Theoptimization system 126 includes a statistics processing module 210 anda dynamic tuning module 220. The network adapter 128 includes a runtimenetwork core 200 and a timer 250. In alternative embodiments, theruntime network core 200 and timer 250 may be part of another component(hardware and/or software) coupled to computing device 100.

The runtime module 200, the statistics processing module 210, and thedynamic tuning module 220 may each be implemented in software, hardware,or a combination of software and hardware.

In certain embodiments, the runtime module 200, the statisticsprocessing module 210, and the dynamic tuning module 220 may beimplemented in integrated circuit components on a motherboard of acomputer (e.g., computing device 100). Thus, the runtime module 200, thestatistics processing module 210, and the dynamic tuning module 220 maybe coupled to a motherboard. Additionally, in alternative embodiments, avideo card, a disk controller and/or other components may be coupled tothe motherboard. Thus, the runtime module 200, the statistics processingmodule 210, and the dynamic tuning module 220 may be coupled to a videocard, disk controller, and/or other components. Also, the networkadapter 128 may be implemented in integrated circuit components on amotherboard of a computer (e.g., computing device 100) and may becoupled to a video card, disk controller, and/or other components.

The statistics processing module 210, the dynamic tuning module 220, andthe runtime network core 200 are coupled to bus 160 and communicate witheach other. In alternative embodiments, rather than communication bybus, the statistics processing module 210, the dynamic tuning module220, and the runtime network core 200 may communicate over an I/O fabricor other connection means. Embodiments may implement aninterrupt-latency timer scheme using a settable timer or a pollingtimer. Embodiments provide a dynamic technique for optimizing optimalITR values for each hardware platform and network profile combination.With embodiments, the optimal ITR values converge during runtime in aquick and efficient way. The optimal ITR values may be used forinterrupt-latency or polling rates.

The runtime network core 220 performs receive and transmit operations.Also, the runtime network core 220 provides timer functionality. Theruntime network core 220 collects statistics during runtime (referred toas “runtime parameters”). The runtime parameters include, for example, atotal bytes counter for the transmit (Tx) direction of traffic and forthe receive (Rx) direction of traffic, a total packets counter for thetransmit (Tx) direction of traffic and for the receive (Rx) direction oftraffic, and an interrupt counter value.

The statistics processing module 210 computes additional statistics(referred to as “statistical parameters”). The statistical parametersmay be computed between time intervals based on runtime statisticscollected by the runtime network core 220. The statistical parametersinclude, for example, traffic rate, average packet size, and averagepackets per interrupt (PPI). The traffic rate parameter is managedseparately for receive and transmit directions of traffic and iscomputed as total bytes transmitted or received in a last timer tick,combined with the negotiated link speed. The average packet sizeparameter is managed separately for receive and transmit directions oftraffic and may be computed as total bytes transmitted or received,respectively, in the last timer tick divided by the total packetstransmitted or received, respectively, in the last timer tick. Theaverage packets per interrupt (PPI) parameter is managed separately forreceive and transmit directions of traffic and is computed as the totalpackets sent or received in the last timer tick divided by the interruptcounter value of the last timer tick.

The dynamic tuning module 220 uses information (i.e., statisticalparameters and, in some embodiments, also runtime parameters) providedby the statistics processing module 210 to determine whether to increaseor decrease the throttling rate in order to converge the desiredsettings in the following (i.e., subsequent) timer periods.

With the receive direction of traffic, the network adapter 128 receivesa packet over the communication path 170 and fires an interrupt when atimer 250 reaches a certain value to indicate to a network driver 120that a packet has to be processed. The network driver 120 receives theinterrupt and processes the packet. If there is a delay because thetimer 250 has not reached a certain value, the network adapter 128stores the packet in memory, without interrupting the network driver120. The interrupt is then issued when the timer 250 reaches a certainvalue.

With the transmit direction of traffic, the network adapter 128transmits a packet over the communication path 170. The network adapter128 issues an interrupt to the network driver 120 to release resourceswhen the timer 250 reaches a certain value.

FIG. 3 illustrates the interaction between a statistics processingmodule 210, a dynamic tuning module 220, and a runtime network core 220.In block 300, the runtime network core 220 collects runtime parametersand forwards these to the statistics processing module 210. In block310, the statistics processing module 210 computes statisticalparameters based on the runtime parameters received from the runtimenetwork core 220 and forwards these to the dynamic tuning module 220. Inblock 320, the dynamic tuning module 220 receives statistical parametersand, in some embodiments, runtime parameters, from the statisticsprocessing module 210 and tunes (i.e., adjusts) the optimal timer valuefor the timer implemented by the runtime network core 220. Also, inblock 300, the runtime network core 220 adjusts a timer value based on anew timer value from the dynamic tuning module 220. As can be seen fromthe cyclic nature of blocks 300-320, optimal timer values converge asthe collected statistics are fed back to the dynamic tuning module 220,which generates new timer values to be used by the runtime network core200.

With embodiments, the convergence of a timer value to an optimal timervalue may be achieved after a few iterations. With the iterativeprocess, embodiments enable tuning timers based on measured feedbackresults (i.e., from previous iterations). Because of the iterativeprocess used to determine the optimal timer value, embodiments may bedescribed as generic, adaptive, and/or self-tuning.

FIG. 4 illustrates operations for determining an optimal ITR value inaccordance with certain embodiments. In certain embodiments, theoperations of FIG. 4 may occur periodically. In certain alternativeembodiments, the operations of FIG. 4 may be triggered by one or moreevents.

In block 400, the runtime network core 200 of the network adapter 128collects runtime parameters from both receive and transmit directions oftraffic and forwards these to the statistics processing module 210. Inblock 410, the statistics processing module 210 of the optimizationsystem 126 computes statistical parameters for both receive and transmitdirections of traffic. In block 420, the dynamic tuning module of theoptimization system 126 determines an advised number of packets perinterrupt for both receive and transmit directions of traffic.

The dynamic tuning module 220 uses several heuristics to determine theadvised number of packets per interrupt. The heuristics described hereinwere defined based on experiments. In various embodiments fewer, more,and/or different heuristics may be used. First, if the packet rate in anetwork decreases, there are to be fewer packets per interrupt. That is,the dynamic tuning module 220 increases responsiveness if the rate dropsor is inherently low. Second, if the average size of a packet decreases,there are to be more packets per interrupt. Packet size corresponds tothe packet transfer time. Thus, more packets of a smaller size aretransferred in a unit of time without latency. Similarly, there may be asmall delay when handling large sized packets (e.g., Jumbo frames thatare over 1500 bytes) because fewer packets of larger size are sent in aunit of time. Third, if the link speed is reduced, there are to be fewerpackets per interrupt (regardless of the measured rate) because it takesmore time to transfer a packet over a slower link.

Quantifying the heuristics described herein produces the followingEquation (1): $\begin{matrix}{{AdvisedPPI} \approx {\frac{{MeasuredMBitsPerSec}*{LinkSpeed}}{f({AveragePacketSize})}*\alpha}} & {{Equation}\quad(1)}\end{matrix}$

Equation (1) is computed for receive and transmit directions of trafficseparately because each direction may have different measured values(e.g., MeasuredMBitsPerSecond, LinkSpeed, and AveragePacketSize).MeasuredMBitsPerSecond may be described as a measured traffic rate (or“transfer rate”) in mega bits per second (Mbps) and is collected by thestatistics processing module 210. LinkSpeed may be described as anegotiated link speed in Mbps. The link speed is negotiated duringOut-Of-Band (OOB) communications. Out-Of-Band communications may bedescribed as those that occur between a sender computing device and areceiver computing device on a different channel that is used for thepurpose of exchanging such information. AveragePacketSize may bedescribed as a measured average packet size in octets (where an octet is8 bits) and is computed by the statistics processing module 210. Thefunction f may be described as a system independent function. In certainembodiments, the function f may be an identity function (i.e., f(x)=x).The function f distributes weight for every average packet size. For theidentity function, weight is proportional to the average packet size.The constant a may be described as a system independent constant value.The constant a defines the aggressiveness of the interrupt moderation.The constant a may be different for receive and transmit directions oftraffic. The constant a may be determined experimentally. The AdvisedPPIindicates an advised number of packets per interrupt (PPI).

With reference to Equation (1), the advised number of packets perinterrupt is approximated by the measured traffic rate times anegotiated link speed, divided by a function over a measured averagepacket size, and multiplied by a constant. In particular, the advisednumber of packets per interrupt is calculated by multiplying a measuredtraffic rate by a negotiated link speed to generate a first value,calculating a function over a measured average packet size to generate asecond value, dividing the first value by the second value to generate athird value, and multiplying the third value by a constant. The resultis an advised number of packets per interrupt for the receive directionof traffic and an advised number of packets per interrupt for thetransmit direction of traffic.

For example, with the constant α= 16/1000, the function ƒ being theidentity function, and a link speed of 1 gigabits per second, thefollowing Table A is defined: TABLE A 20% 50% 100% network networknetwork utilization utilization utilization 64 byte 50 125 250 packets1514 byte 2 5 10 packets 16K byte 1 1 1 packets

In Table A, with reference to Equation (1), the first column identifiesan average packet size (AveragePacketSize), and the first row identifiesnetwork utilization. The network utilization is MeasuredMBitsPerSecondrelative to link speed. For example, 10 megabits per second (Mbps)results in 1% network utilization on a 1 gigabits per second (Gbps) linkspeed and in 100% network utilization in a 10 megabits per second linkspeed. Merely to provide an example, Table A is defined for a 1 gigabitsper section link speed, but any link speed may be used. Thus, networkutilization as a percentage (%) is used in Table A, rather than actualtraffic rate (i.e., MeasuredMBitsPerSecond). Thus, for a givenAveragePacketSize and network utilization, the dynamic tuning module 220is able to provide an AdvisedPPI.

As another example, with the constant α= 16/1000, the function ƒ beingthe identity function, and a link speed of 100 Mbps, the following TableB is defined: TABLE B 20% 50% 100% network network network utilizationutilization utilization 64 byte 5 12 25 packets 1514 byte 1 1 1 packets16K byte 1 1 1 packets

With the examples illustrated with Table A and Table B, the dynamictuning module 220 uses Equation (1) to recommend a number of packets perinterrupt (PPI) based on the measured parameters on the hardwareplatform and the network profile.

The values in Table A and Table B may be determined by, for example,experimental measurements over a large variety of hardware platforms andnetwork profiles. The values in Table A and Table B may change based ona desired rate of packets per interrupt.

In block 430, the dynamic tuning module 220 of the optimization system126 adjusts the current timer values for both receive and transmitdirections of traffic based on the advised numbers of packets perinterrupt. That is, the timer value for each direction of traffic istuned to match the advisedPPI using Equation (2). $\begin{matrix}{{new\_ TimerVal} \approx {{old\_ TimerVal}*\frac{AdvisedPPI}{{Measured\_ Average}{\_ PPI}}}} & {{Equation}\quad(2)}\end{matrix}$

In Equation (2), the new timer value (new_TimerVal) is determined basedon the current timer value (old_TimerVal). The new timer value isadjusted (increased or decreased) in a proportional manner to thecurrent timer value, where the proportion is determined byAdvisedPPI/Measured-Average_PPI. The measured average packet perinterrupt (Measured_Average PPI) is collected by the statisticsprocessing module 210 and is an average number of packets per interrupt.In certain embodiments, the timer value may be small, but not zero. Incertain embodiments, based on a measured simulation, the timer convergesto an optimal value.

In particular, for each direction of traffic, a new timer value isapproximated by an old timer value multiplied by an advised number ofpackets per interrupt for that direction of traffic divided by anaverage number of packets per interrupt. Thus, the new timer value iscalculated by dividing an advised number of packets per interrupt for aparticular direction of traffic by an average number of packets perinterrupt to generate a first value and multiplying an old timer valueby the first value. The result is a transmit timer value (TxTimer) and areceive timer value (RxTimer).

In block 440, the dynamic tuning module 220 of the optimization system126 calculates a new timer value (for both receive and transmitdirections of traffic) based on the adjusted current timer values. Eachdirection of traffic (receive and transmit) has a separate Advised PPIand a timer value. In certain embodiments, the dynamic tuning module 220uses Equation (3) to determine a timer value (for both receive andtransmit), which is a refined median based on the receive (Rx) andtransmit (Tx) values. $\begin{matrix}{{TimerVal} = \frac{{{TxTimer}*{TxLinkUtilization}} + {{RxTimer}*{RxLinkUtilization}}}{{TxLinkUtilization} + {RxLinkUtilization}}} & {{Equation}\quad(3)}\end{matrix}$

The TxTimer value is the new_TimerVal determined for transmit. TheTxLinkUtilization value is computed as a ratio between the traffic rateand the link speed. The RxTimer value is the new_TimerVal determined forreceive. RxLinkUtilization value is computed as a ratio between thetraffic rate and the link speed. In particular, the timer value(TimerVal) is calculated by multiplying the transmit timer value by thetransmit link utilization value to generate a first value, multiplyingthe receive timer value by the receive link utilization value togenerate a second value, adding the first value and the second value togenerate a third value, adding the transmit link utilization and thereceive link utilization to generate a fourth value, and dividing thethird value by the fourth value. Thus, the timer value may beincremented in a proportional manner, rather than in increments.

In block 450, a timer is set with the new timer value. In particular,the dynamic tuning module 220 of the optimization system 126 forwardsthe calculated timer value to the runtime network core 200 of thenetwork adapter 128, which updates the timer value for a timer 250(e.g., an interrupt-latency timer or for a polling rate timer). Incertain embodiments, one timer 250 may be used for both the receive andtransmit directions of traffic. In this manner, embodiments provide atechnique that enables determining a timer value for an InterruptThrottling Rate (ITR) scheme that uses a settable timer or a pollingtimer.

By optimizing timer values, embodiments enable optimizinginterrupt-latency and polling rates for various hardware platform andnetwork profile combinations and improve overall system performance in amanner that is independent of a hardware platform and a network profile.

Intel is a registered trademark and/or common law mark of IntelCorporation in the United States and/or foreign countries.

Additional Embodiment Details

The described embodiments may be implemented as a method, apparatus (orsystem) or article of manufacture using programming and/or engineeringtechniques to produce software, firmware, hardware, or any combinationthereof. The terms “article of manufacture” and “circuitry” as usedherein refer to a state machine, code or logic implemented in hardwarelogic (e.g., an integrated circuit chip, Programmable Gate Array (PGA),Application Specific Integrated Circuit (ASIC), etc.) or a computerreadable medium, such as magnetic storage medium (e.g., hard diskdrives, floppy disks, tape, etc.), optical storage (CD-ROMs, opticaldisks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs,ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.).Code in the computer readable medium is accessed and executed by aprocessor. When the code or logic is executed by a processor, thecircuitry may include the medium including the code or logic as well asthe processor that executes the code loaded from the medium. The code inwhich preferred embodiments are implemented may further be accessiblethrough a transmission media or from a file server over a network. Insuch cases, the article of manufacture in which the code is implementedmay comprise a transmission media, such as a network transmission line,wireless transmission media, signals propagating through space, radiowaves, infrared signals, etc. Thus, the “article of manufacture” maycomprise the medium in which the code is embodied. Additionally, the“article of manufacture” may comprise a combination of hardware andsoftware components in which the code is embodied, processed, andexecuted. Of course, those skilled in the art will recognize that manymodifications may be made to this configuration, and that the article ofmanufacture may comprise any suitable information bearing medium.Additionally, the devices, adaptors, etc., may be implemented in one ormore integrated circuits on the adaptor or on the motherboard.

The term logic may include, by way of example, software or hardwareand/or combinations of software and hardware.

The illustrated operations of FIG. 4 show certain events occurring in acertain order. In alternative embodiments, certain operations may beperformed in a different order, modified or removed. Moreover,operations may be added to the above described logic and still conformto the described embodiments. Further, operations described herein mayoccur sequentially or certain operations may be processed in parallel.Yet further, operations may be performed by a single processing unit orby distributed processing units.

The foregoing description of various embodiments has been presented forthe purposes of illustration and description. It is not intended to beexhaustive or limiting. Many modifications and variations are possiblein light of the above teachings.

1. A method capable of determining a timer value, comprising:determining an advised number of packets per interrupt for both receiveand transmit directions of traffic; adjusting current timer values forboth receive and transmit directions of traffic based on the determinedadvised numbers of packets per interrupt; and calculating a new timervalue to be used for both receive and transmit directions of trafficbased on the adjusted current timer values.
 2. The method of claim 1,further comprising: collecting runtime parameters from both receive andtransmit directions of traffic.
 3. The method of claim 1, furthercomprising: computing statistical parameters for both receive andtransmit directions of traffic.
 4. The method of claim 1, whereindetermining the advised number of packets per interrupt for eachdirection of traffic further comprises: multiplying a measured trafficrate by a negotiated link speed to generate a first value; calculating afunction over a measured average packet size to generate a second value;dividing the first value by the second value to generate a third value;and multiplying the third value by a constant.
 5. The method of claim 1,wherein adjusting the current timer values for each direction of trafficfurther comprises: dividing an advised number of packets per interruptfor that direction of traffic by an average number of packets perinterrupt to generate a first value; and multiplying an old timer valueby the first value.
 6. The method of claim 1, wherein the current timervalues comprise a transmit timer value and a receive timer value andwherein calculating the new timer value further comprises: multiplyingthe transmit timer value by a transmit link utilization value togenerate a first value; multiplying the receive timer value by a receivelink utilization value to generate a second value; adding the firstvalue and the second value to generate a third value; adding thetransmit link utilization and the receive link utilization to generate afourth value; and dividing the third value by the fourth value.
 7. Themethod of claim 1, further comprising: setting a timer with the newtimer value, wherein interrupts are fired based on the new timer value.8. An article of manufacture, wherein the article of manufacturecomprises a computer readable medium storing instructions, and whereinthe article of manufacture is operable to: determine an advised numberof packets per interrupt for both receive and transmit directions oftraffic; adjust current timer values for both receive and transmitdirections of traffic based on the determined advised numbers of packetsper interrupt; and calculate a new timer value to be used for bothreceive and transmit directions of traffic based on the adjusted currenttimer values.
 9. The article of manufacture of claim 8, wherein thearticle of manufacture is operable to: collect runtime parameters fromboth receive and transmit directions of traffic.
 10. The article ofmanufacture of claim 8, wherein the article of manufacture is operableto: compute statistical parameters for both receive and transmitdirections of traffic.
 11. The article of manufacture of claim 8,wherein for the instructions for determining the advised number ofpackets per interrupt for each direction of traffic, the article ofmanufacture is operable to: multiply a measured traffic rate by anegotiated link speed to generate a first value; calculate a functionover a measured average packet size to generate a second value; dividethe first value by the second value to generate a third value; andmultiply the third value by a constant.
 12. The article of manufactureof claim 8, wherein for the instructions for adjusting the current timervalues for each direction of traffic, the article of manufacture isoperable to: divide an advised number of packets per interrupt for thatdirection of traffic by an average number of packets per interrupt togenerate a first value; and multiply an old timer value by the firstvalue.
 13. The article of manufacture of claim 8, wherein the currenttimer values comprise a transmit timer value and a receive timer valueand wherein for the instructions for calculating the new timer value,the article of manufacture is operable to: multiply the transmit timervalue by a transmit link utilization value to generate a first value;multiply the receive timer value by a receive link utilization value togenerate a second value; add the first value and the second value togenerate a third value; add the transmit link utilization and thereceive link utilization to generate a fourth value; and divide thethird value by the fourth value.
 14. The article of manufacture of claim8, wherein the article of manufacture is operable to: set a timer withthe new timer value, wherein interrupts are fired based on the new timervalue.
 15. A system, comprising: a video card; a network adapter; and adynamic tuning module coupled to the network adapter and to the videocard; wherein the dynamic tuning module is operable to: determine anadvised number of packets per interrupt for both receive and transmitdirections of traffic; adjust current timer values for both receive andtransmit directions of traffic based on the determined advised numbersof packets per interrupt; and calculate a new timer value for a timer tobe used for both receive and transmit directions of traffic based on theadjusted current timer values.
 16. The-system of claim 15, furthercomprising: a runtime network core coupled to the network adapter,wherein the runtime network core is operable to collect runtimeparameters from both receive and transmit directions of traffic.
 17. Thesystem of claim 15, further comprising: a statistics processing module,wherein the statistics processing module is operable to computestatistical parameters for both receive and transmit directions oftraffic.
 18. The system of claim 15, wherein when determining theadvised number of packets per interrupt for each direction of traffic,the dynamic tuning module is operable to: multiply a measured trafficrate by a negotiated link speed to generate a first value; calculate afunction over a measured average packet size to generate a second value;and divide the first value by the second value to generate a thirdvalue; and multiply the third value by a constant.
 19. The system ofclaim 15, wherein when adjusting the current timer values for eachdirection of traffic, the dynamic tuning module is operable to: dividean advised number of packets per interrupt by an average number ofpackets per interrupt for that direction of traffic to generate a firstvalue; and multiply an old timer value by the first value.
 20. Thesystem of claim 15, wherein the current timer values comprise a transmittimer value and a receive timer value and wherein, when calculating thenew timer value, the dynamic tuning module is operable to: multiply thetransmit timer value by a transmit link utilization value to generate afirst value; multiply the receive timer value by a receive linkutilization value to generate a second value; add the first value andthe second value to generate a third value; add the transmit linkutilization and the receive link utilization to generate a value; anddivide the third value by the fourth value.
 21. The system of claim 15,further comprising; a runtime network core, wherein the runtime networkcore is operable to set the timer with the new timer value, whereininterrupts are fired based on the new timer value.
 22. A system,comprising: a disk controller; a network adapter, wherein the networkadapter includes a timer and is coupled to the disk controller; aruntime network core coupled to the network adapter and to the diskcontroller; a statistics processing module coupled to the networkadapter and to the disk controller; and a dynamic tuning module coupledto the network adapter and to the disk controller.
 23. The system ofclaim 22, wherein the runtime network core is operable to collectruntime parameters from both receive and transmit directions of traffic.24. The system of claim 23, wherein the statistics processing module isoperable to compute statistical parameters for both receive and transmitdirections of traffic using the collected runtime parameters.
 25. Thesystem of claim 24, wherein the dynamic tuning module is operable tocalculate a new timer value for the timer to be used for both receiveand transmit directions of traffic based on the computed statisticalparameters.